package com.example.mysql.学习笔记.高级.数据库的优化之索引.数据库的设计规范之范式;

public class 前三范式 {
}
/**
 * 2.4第一范式(1st NF)
 * 第一范式主要是确保数据表中每个字段的值必须具有  原子性，
 * 也就是说数据表中每个字段的值为不可再次拆分的最小数据单元。
 * 我们在设计某个字段的时候，对于字段X来说，不能把字段X拆分成字段X-1和字段X-2。
 * 事实上，任何的DBMS(数据库管理系统)都会满足第一范式的要求, 不会将字段进行拆分。
 *
 * 简单来说，不能多个信息合成一个在字段
 * 但是比如地址  中国 省 市 区啥的  可以区分  但是有时候没必要
 *
 */
/**
 * 第二范式
 * 第二范式要求，在满足第--范式的基础上，还要满足数据表里的每-条数据记录，都是可唯--标识的。
 * 而且所有非主键字段,都必须"完全依赖主键",不能只依赖主键的一部分。
 *      比如组合主键(两个字段组成主键)
 * 如果知道主键的所有属性的值，就可以检索到任何元组(行)的任何属性的任何值。
 * (要求中的主键， 实可以拓展替换为候选键)。
 *
 * 比如 1
 * 成绩表(学号, 课程号,成绩)关系中，(学号, 课程号)可以决定成绩，
 * 但是学号不能决定成绩，课程号也不能决定成绩，
 * 所以“(学号,课程号)→成绩'就是完全依赖关系。
 * 比如 2
 * 比赛表player_game,里面包含球员编号、姓名、年龄、比赛编号、比赛时间和比赛场地等属性,
 * 这里候选键和主键都为(球员编号,比赛编号)，我们可以通过候选键(或主键)来决定如下的关系:
 * (球员编号，比赛编号)一(姓名，年龄，比赛时间，比赛场地，得分)
 * 球员编号                决定    姓名，年龄
 * 比赛编号                决定    比赛时间，比赛场地
 * 球员编号，比赛编号        决定    得分
 * 这样的话  一个表就不行了，这样不满足第二范式
 * 需要三张表
 * 球员表     球员编号，姓名，年龄
 * 比赛表     比赛编号，比赛时间，比赛场地
 * 得分表     球员编号，比赛编号，得分
 *
 * 对于非主属性来说，并非完全依赖候选键。这样会产生怎样的问题呢?
 * 1.数据冗余: 如果一个球员可以参加m场比赛，那么球员的姓名和年龄就重复了m-1次。一个比赛也可能会
 * 有n个球员参加，比赛的时间和地点就重复了n-1次。
 * 2. 插入异常:如果我们想要添加一场新的比赛，但是这时还没有确定参加的球员都有谁,那么就没法插入。
 * 3.删除异常: 如果我要删除某个球员编号，如果没有单独保存比赛表的话,就会同时把比赛信息删除掉。
 * 4.更新异常: 如果我们调整了某个比赛的时间，那么数据表中所有这个比赛的时间都需要进行调整，否则就会
 * 出现-场比赛时间不同的情况。
 *
 * 小结:第二范式(2NF) 要求实体的属性完全依赖主关键字。如果存在不完全依赖，那么这个属性和主关键字
 * 的这一部分应该分离出来形成一 个新的实体， 新实体与元实体之间是一对多的关系。
 *
 *
 */

/**
 *2.6第三范式(3rd NF)
 * 第三范式是在第二范式的基础上,确保数据表中的每一个非主键字段都和主键字段直接相关，
 * 也就是说，要求数据表中的所有非主键字段不能依赖于其他非主键字段。
 * (即,不能存在非主属性A依赖于非主属性B,非主属性B依赖于主键C的情况，即存在“A-→B-→C"”的决定关系)
 *
 * 通俗地讲，该规则的意思是所有 非主键属性之间不能有依赖关系 ，必须相互独立。
 * 这里的主键可以拓展为候选键。
 *
 * 符合3NF后的数据模型通俗地讲，2NF和3NF通常以这句话概括:
 * “每个非键属性依赖于键，依赖于整个键，并且除了键别无他物”。
 *
 *
 *
 */
/**
 * 2.7小结
 * 关于数据表的设计，有三个范式要遵循。
 * (1) 第一范式(1NF) ，确保每列保持原子性
 *  数据库的每一列都是不可分割的原子数据项，不可再分的最小数据单元，
 *  而不能是集合、数组、记录等非原子数据项。
 * (2)第二范式(2NF) ，确保每列都和主键完全依赖
 *   尤其在复合主键的情况下，非主键部分不应该依赖于部分主键。
 * (3)第三范式(3NF) 确保每列都和主键列直接相关，而不是间接相关
 * 范式的优点:数据的标准化有助于消除数据库中的数据冗余，
 *        第三范式(3NF)通常被认为在性能、扩展性和数据完整性方面达到了最好的平衡。
 * 范式的缺点:范式的使用，可能降低查询的效率。
 *         因为范式等级越高，设计出来的数据表就越多、越精细，数据的冗余度就越低，
 *         进行数据查询的时候就可能需要关联多张表,这不但代价昂贵，也可能使一些索引策略无效。
 *
 * 范式只是提出了设计的标准，实际上设计数据表时，未必--定要符合这些标准。
 * 开发中，我们会出现为了性能和读取效率违反范式化的原则，
 * 通过增加少量的冗余或重复的数据来提高数据库的读性能，
 * 减少关联查询, join 表的次数，实现空间换取时间的目的。
 * 因此在实际的设计过程中要理论结合实际，灵活运用。
 *
 * 范式本身没有优劣之分，只有适用场景不同。没有完美的设计，只有合适的设计，我们在数据表的设计中，
 * 还需要根据需求将范式和反范式混合使用。
 *
 */

